IEEE 1588v2 Standard for a precision clock synchronization protocol for networked measurement and control systems defines a precision timing protocol, PTP, at the packet layer, which is used to distribute frequency and/or Time of Day ToD (phase). The protocol defines event messages and general PTP messages. Event messages are timed messages having an accurate timestamp that is generated at both transmission and receipt. The set of event messages consists of: Synch; Delay_Req; Pdelay_Req; and Pdelay_Resp.
The protocol defines how real-time clocks in a system synchronise with each other. The clocks in the system are arranged in a master-slave synchronization hierarchy with a grandmaster (GM) clock at the top of the hierarchy which sets the reference time for the system. Slave clocks synchronise with a grand master (GM) clock by exchanging PTP timing messages. Each GM issues PTP event messages time stamped with ToD. Each slave estimates the delay between its respective GM and itself, and adds this delay to the received ToD, to achieve the current ToD, thereby adjusting their clock to the time of their GM.
Newer generations of mobile communications network technology focus on increasing the data throughput, uplink and downlink in a network. This requires tighter phase alignment between neighbouring towers in the network to facilitate hand-over. IEEE1588v2 can provide this phase alignment where other classical synchronization methods cannot.
Transparent Clocks (TC) and Boundary Clocks (BC) are two different methods defined by IEEE 1588v2. A Boundary clock, located at a network element of a communications network, is able to process the PTP event messages received by its ports, to recover the best frequency and phase information and to synchronize the network element in compliance with them, and then to generate the relative PTP event message to downstream network elements of the network through its egress ports. A Transparent clock, located at a network element of a communications network, measures the transit delay (or residence time) of PTP event messages across the network element and inserts this information in a correction field of the PTP event message itself or in a related follow up message (depending on the actual implementation). Thus a “fast” message will have a small correction value, and a packet going through a highly congested switch network element will have a large value. In the end the slave can work out, message by message, what network delays the message has experienced.
A Transport Operator has to provide its mobile customers with IEEE1588 based transport services, illustrated in FIG. 1, configured to provide the best final quality. In the case of an optical transport network, OTN, configured according to ITU-T Recommendation G.709, the following three options are being investigated for implementation as standards: PTP as a client (over Ethernet) [Transparent Transport]; PTP in the OTN Overhead and BC in the OTN network elements; and PTP in the optical supervisory channel, OSC, and BC in the OTN network elements and Line Amplifiers.
The first option may look like the simplest one; the OTN network is unaware of the IEEE1588 messages that are transported across it, and the OTN network maps and transports communications traffic flows (e.g. 10 Gb Ethernet) without knowing their contents. Therefore the IEEE1588 messages contained within OTN packets pass through the OTN network in a transparent way. The first option adheres to the OTN basic concept of enabling transparent transport of client communications traffic and it is suitable for multi-operator networks (as there is no need to extract and process PTP messages). However it suffers the disadvantage of requiring control of all the possible sources of asymmetries within the network, such as: Ethernet Client Mapping and Demapping; forward error correction, FEC; Different Fiber Lengths; Different Wavelengths; Protection Switching; ODU multiplexing and so on.
The second option offers the benefit that asymmetries and noise due to OTN mapping/demapping and FEC are avoided. However it suffers the disadvantage that it goes against the basic principle of transporting client traffic over an OTN network. In practice the second option would be feasible only in the case of a single network operator, where the OTN network element at the end handles the network time. In order to handle the timing of multiple clients with this approach, this option would require an unrealistic implementation of the OTN network element in which multiple BC instances are implemented, each of them handling the time of a different client. This option also suffers the disadvantages of requiring synchronization of all network elements in the OTN network (i.e. handling of an additional synchronization network), asymmetries due to fibre length and dispersion compensating fibre, DCF, are still to be addressed, and specific hardware would be required in the OTN network elements.
In the third option, for each OTN network element and Line Amplifier PTP messages are extracted from the OSC, terminated, regenerated by an IEEE1588 Boundary clock, and then reinserted in the OSC. This means that symmetries and noise due to OTN mapping/demapping, FEC and DCF are resolved. However this option also goes against the basic principle of transporting client traffic over an OTN network. In practice it would be feasible only in case of a Single network operator, where the OTN network element at the end handles the network time. In order to handle the timing of multiple clients with this approach, it would require an unrealistic implementation of the OTN network element in which multiple BC instances are implemented, each handling the time of a different client. The third option also suffers the problems of requiring synchronization of all network elements in the OTN network (i.e. handling of an additional synchronization network), specific hardware would be required in the OTN network elements and Line Amplifiers, and asymmetries due to fibre length are still to be addressed.
The current options are therefore each characterized by some limitations. One main limitation with the second and third options is the need to handle a specific synchronization network where all OTN nodes need to be synchronized. Another limitation with the second and third options is the ability to only support a single network operator. The first option is the only one suitable for use in multi-operator networks but its implementation would require significant modifications to be implemented in the OTN network requirements and in the OTN network hardware to achieve an acceptable level of quality.